Transactional Orc

Transactions provide a language construct that programmers can use to specify that operations execute atomically, in isolation from all computation outside the transaction. Transactions permit optimistic concurrency for accesses to shared data, which may improve performance over locking mechanisms. Transactions also allow programmers to specify atomic regions in a composable way, which locks do not permit. Although transactions are theoretically capable of these performance and programmability improvements, researchers have found it difficult to exploit these benefits in practice via transactional memory. Most transactional memory implementations provide a single transaction management policy. Which policy is desirable, however, often differs with the memory location. Some objects are highly contended and may benefit from deferred updates, while others seldom suffer from contention and may benefit from inplace update, for instance. By implementing transactions in Orc, a language that separates computation from concurrency, we allow different transaction management policies to be used in a single program, and even within a single transaction. Although composability is one of the key programmability goals of transactions, most nesting solutions also suffer from high overheads, unnecessary restrictions, unintuitive nesting policies, or excessive aborts at runtime that may limit gains in programmability. Orc provides nested parallel transactions, and allows computations and data structures to decide how, and whether, they will support nested transactions.